PD ROM 1/PD ROM Volume I - Macintosh Software from BMUG (1988).iso/Electronic Messages/USEnet Digests/USEnet Vol. 4/USEnet 4.41

Text File | 1988-06-15 | 24.2 KB | 637 lines | [TEXT/ttxt]

28-Mar-88 11:59:39-PST,25408;000000000000
Return-Path: <[e-mail]>
Received: from RELAY.CS.NET by SUMEX-AIM.Stanford.EDU with TCP; Mon, 28 Mar 88 11:57:16 PST
Received: from relay2.cs.net by RELAY.CS.NET id bh16570; 28 Mar 88 11:52 EST
Received: from relay.cs.net by RELAY.CS.NET id aa19415; 28 Mar 88 11:31 EST
Received: from sdr.slb.com by RELAY.CS.NET id ah19391; 28 Mar 88 11:27 EST
Date: Mon, 28 Mar 88 09:34 EDT
From: Jeffrey Shulman <[e-mail]>
Subject: Usenet Mac Digest V4 #41
To: [e-mail], [e-mail]
X-VMS-To: in%"[e-mail]",in%"[e-mail]"

Date: Mon 28 Mar 88 09:34:10-GMT
From: Jeff Shulman <SHULMAN@SDR>
Subject: Usenet Mac Digest V4 #41
To: Usenet-List: ;
Message-ID: <575544851.0.SHULMAN@SDR>
Mail-System-Version: <VAX-MM(218)+TOPSLIB(129)@SDR>

Usenet Mac Digest     Friday, March 25, 1988         Volume 4 : Issue 41

Today's Topics:
     Transputer development card for MacII
     MacApp Browser
     Help for a sick friend...
     Re: Hard disks
     HD
     PrintMonitor -- Out of Memory Problems
     Re: Photo of Mac II Monitor
     Re: MacApp Browser
     nVIR virus - you may think you don't have it... (2 messages)
     Re: PrintMonitor -- Out of Memory Problems
     QuickerGraf 1.1
     Re: Prototyper vs. Doing it Yourself
     PrJobMerge, etc.
     Hard Disk Icon
     Filling an arbitrary quardrangle
     Asher Engineering ADB Trackball review.
     Re: Quickergraf bugs...

----------------------------------------------------------------------

From: [e-mail] (LEIGHTON 336.25.25 p5392)
Subject: Transputer development card for MacII
Date: 17 Mar 88 18:06:27 GMT
Organization: L.I.T.P, Universite P7, PARIS

Where can I find development systems with at least two transputers
(T800), for the Mac II ? (I know of many systems for the IBM-PC...)
Thank you for your answers!

        Vicente Sanchez-Leighton

        ...!mcvax!inria!litp!vsl



------------------------------

From: [e-mail] (D. Ranson CNET)
Subject: MacApp Browser
Date: 16 Mar 88 08:13:39 GMT


I am having difficulties using the MacApp Browser distributed by the
MacApp Developpers Association. I have parsed successfully all the
source files of MacApp v1.1.1, but the browser is unable to find the
source code for most of the methods (especially those in UMacApp). Other
units, e.g. UObject or UList, give correct results. Am I missing
something, such as a specific order to parse the files?

A totally unrelated question: what is the status of the new Mac
newsgroups (programmer, hypercard)? The news sites I have access to in
Europe have not received the creation messages. Are these groups "US
only"?

    Daniel Ranson
    ...!mcvax!inria!cnetlu!ranson


------------------------------

From: [e-mail] (Paul Dietz)
Subject: Help for a sick friend...
Date: 18 Mar 88 11:53:57 GMT
Organization: Carnegie-Mellon University, CS/RI

I guess it was bound to happen sometime. After three years of Mac-ing
(first a 512k, and then a II) I just had my first hardware failure. A
friend of mine was using my MacII, and decided he didn't like the
keyboard arrangement. So he unplugged the keyboard, and apparantly
accidently connected the two desktop bus ports directly together for a
moment. (I was in the ol' WC while this was happening...) Anyhow, the
machine no longer responds to either the mouse or the keyboard.

The tale continues.

I took my sick friend to the campus computer store for repair. I
explained the situation, and suggested that the output drivers on the
ADB (Apple Desktop Bus) had been fried, and that these should be
replaced first.

Did I mention that this all happened a few days out of warrenty?

They agreed with my diagnosis, but informed me that as an authorized
Apple dealer, they are not allowed to replace chips. Instead, they swap
the entire logic board. Estimated cost: $320.

Did I mention that my thesis is on this machine, and that I'd really
like to graduate?

So, I swallowed my pride, and my wallet, and gave the go ahead.

Has this happened to you? I noticed a couple of machines in the computer
store with the same problem. Apparently it's quite common. So why
doesn't Apple socket these parts, and explain to their dealers how to
replace them? Are there people out there who do these sorts of
"unauthorized" repairs?

My need for my machine was desperate this time. But next time, I'll fix
it myself. Now, all I need is a good set of schematics, and a source for
Apple parts. Will Apple sell these? Or is it too busy unloading money
from the trucks that just keep rolling in...

(By the way, just in case you think that Apple-care is a good deal, it
would have cost me about $1000 for the last three years, while I've only
had this one, "not-my-fault" problem for ~$300.)

I will download sympathy email cards as soon as my machine is feeling
well enough...
--
Paul H. Dietz                                        ____          ____
Dept. of Electrical and Computer Engineering        / oo \        <_<\\\
Carnegie Mellon University                        /|  \/  |\        \\ \\
--------------------------------------------     | | (  ) | |       | ||\\
"If God had meant for penguins to fly,             -->--<--        / / |\\\  /
he would have given them wings."            _________^__^_________/ / / \\\\-


------------------------------

From: [e-mail]
Subject: Re: Hard disks
Date: 18 Mar 88 04:43:00 GMT


The 40Mb and 80Mb Apple (and CMS) disks are made by quantum.  The access
time is 26.5ms on these disks.  So the 60Mb disk is slower (40ms).  In
fact, 40ms is "unusually" slow for a 60Mb disk.  That's probably part of
the reason why they're cheaper.

Seagate is the highest-volume manufacturer of sealed hard disks (this
from a seagate employee).  I think they make more than 1 million disks
per month, and have almost half (50%) of the market for hard-disk units.
 So it is understandable that their drives are the cheapest.


------------------------------

From: [e-mail] (The Alt)
Subject: HD
Date: 18 Mar 88 21:05:04 GMT
Organization: University of California, San Diego

I bought a Mac SE through the university. From day 1, I had problems
with the Hard Disk. When not installed as the startup disk, it
periodically refused to show up on the desk top. If I turned the machine
off and tried again, I had a good chance of getting it to appear. I have
a similar problem now that it is the Startup disk. Sometimes it works
and other times it doesn't.

I took it back to the school, an authorized apple dealer, and had them
check it out. "Nothing is wrong with it," they told me. "You can try
putting a newer version of finder and the system on, but I don't know
what else to tell you." So I did. Guess what, it still does it. I don't
know if it's coincidal but, it seems to be doing it a little less
frequently. However, it still does it.

Has anyone out there had a similar experience?(With the machine or the
dealers) Any suggestions? Help

                                           Ron


------------------------------

From: [e-mail] (Jim Meiss)
Subject: PrintMonitor -- Out of Memory Problems
Date: 18 Mar 88 22:38:19 GMT
Organization: The University of Texas at Austin, Austin, Texas


    I have been having problems lately using Background Laser printing with
our Laserwriter Plus, from my MacPlus running Multfinder. What happens
is that PrintMonitor tells me it has a problem, which "Not enough memory
to print this now, you might close a desk accsory..."  (note the
mis-spelling!)
    Well, I get this even when I have no other application running besides
the finder, leaving me some 600K free. While I was investigating this I
noticed that Printmonitor was filling up its default 78K partition, and
suspecting this was the problem I increased it to 120K. Voila, no
problems.
    This problem is intermittant. It doesn't happen for all files,and I
just tried setting the partiton back to 78, and reprinting the TechNote
that I was just having trouble with--while running Versaterm--and it
worked. Nothing like intermittancy to cloud the issue.
    Furthermore, I don't seem to remember having this problem a few weeks
ago....so what could have changed? I'm using Font/DA Juggler, but the
problem persists when I turn it off. I have the Application Menu INIT,
and the AutoBlack Screen Idler installed.
    Anyone else have this problem?
    Also, why does Apple have such an uniformative message for this
error--and why does the message have a spelling error in it :-) !!


                Jim Meiss
                 [e-mail]
                [e-mail]


------------------------------

From: [e-mail] (Joseph Nathan Hall)
Subject: Re: Photo of Mac II Monitor
Date: 18 Mar 88 21:36:57 GMT
Organization: North Carolina State University, Raleigh, NC

In article <[e-mail]> [e-mail] (Kenneth H. Jacker)
writes:
>
>    I need to make color slides of a Mac II screen.  My
>system uses Apple's High-Res RGB monitor.
>
>    Any suggestions regarding film type, shutter speed,
>aperture, and/or exposure time?
>

I've photographed a few CRTs.  While I can't give you exact exposure
info I can offer a few helpful hints.

1)    The room must be DARK.  Completely.  Any light spilling onto the
    screen will ordinarily appear as a dim, putrid green (if your
    lighting is fluorescent).  If you can't darken the room completely
    it will be necessary for you to construct some sort of shade
    around the screen.  Also you'll want to remove fingerprints and
    dust, other crud, etc., from the screen.

2)    Use shutter speeds substantantially longer than the display's
    refresh rate.  I suggest 1/8 second or longer.  I've usually
    used 1/2 second or more.  Obviously you'll have to set your
    exposure manually.


3)    Most electronic metering systems will not properly meter a
    flickering source (like a CRT).  Older "electromechanical" meters
    will.  (Luna-Pro, cheap handheld meters, most needle-type meters
    in general.)  You can't use your camera's meter to
    read the exposure, unless it's of the electromechanical type.

4)    When you meter the screen, turn off the lights and place the meter
    directly on the display, pointing it at a NEUTRAL, relatively dim
    area.  If you're photographing a display of lines, you'll have to
    meter something else to get your exposure.  Meters are calibrated for
    a reference subject of 18% reflectance.  Ideally, you'd want to
    meter something that was 18% as luminous as your display's "white,"
    but there's usually no practical way to do this.  So you'll have
    to guess, and...

5)    BRACKET YOUR EXPOSURES.  A minimum of three exposures per display
    is advisable.  If your exposure turns out to be 1/4" at f/8, you
    should take 1 picture at 1/4" as planned, and then one at, say,
    1/6" and one at 1/3".  If you're not too sure about what you're
    doing I suggest you fire off a test roll or two.  Write down
    EVERYTHING as you conduct your test.  Bracket by half- or third-
    stops in both directions from your estimated exposure, 1 or 2 stops
    each way.  Record the settings of brightness and contrast controls
    on the display.  Be sure when you look at the results of your
    test that you view the slides properly, either in a good viewer or
    as they will be projected.  Most slides that are a half-stop
    under- or over-exposed look OK when just held up to the ceiling
    lights or whatever.

6)    If your slides have a pronounced color bias you'll need to try
    filtration.  Use CC ("color correction") filters, and experiment until
    you succeed.  This is a complicated procedure for the amateur
    photographer, but basically you'll need gelatin filters and
    a gelatin filter holder, both of which can be ordered from a good
    photo supply store.

7)    A mild telephoto lens (about "portrait length"-- 85-110 mm) is best
    unless you're photographing a particularly large screen.  Then
    you'll want an even longer lens.  You need to be far enough back
    from the display to eliminate perspective effects and to make sure
    the entire screen will be held in focus.  In particular you need
    to be far enough back from the screen to eliminate "bowing" of
    the display due to the CRT's curvature.

8)    A GOOD TRIPOD is essential.  A remote shutter release is almost
    as essential, unless you have either a self-timer or have a very
    light touch on your shutter button.

Films:  Different films react different ways to different screen
phosphors.
    You might have had great luck with Ektachrome 100 on your
    VAXstation but that doesn't mean it'll work as well photographing
    your TV.  I suggest you try Ektachrome 100 or Kodachrome 64 at
    first.  If you have problems with the color balance you can always
    try a couple of other slide films before proceeding to the (ugh)
    filters.

If your results aren't good at first, keep trying.  Good slides of
computer graphics are a little tricky to make, but not impossible.

    -joseph

(I thought I'd post this instead of replying directly, since I think
it's probably of interest to a few other folks.  Sorry it it wasn't.)

/*
 * We all have our own opinions here.
 */


------------------------------

From: [e-mail] (Duane Williams)
Subject: Re: MacApp Browser
Date: 19 Mar 88 01:53:22 GMT
Organization: Carnegie-Mellon University, CS/RI


Re:
| I am having difficulties using the MacApp Browser ...
| the browser is unable to find the source code for most of the methods
| (especially those in UMacApp). Other units, e.g. UObject or UList, give
| correct results.

I presume that you mean that the Browser is finding the source files,
but not accurately locating the methods.  This will happen if you edit
the source files after you run the Parser, which seems to just save the
offset for each of the methods.  Each time you edit one of the source
files you have to reparse it.  You should select the names of the files
that need reparsing, select the reparse menu item (which marks the files
for reparsing), and then select the parse files menu item.

(You really shouldn't be editing UMacApp at all, if that's what you're
doing.)
--
uucp: ...!seismo!cmucspt!me.ri.cmu.edu!dtw
arpa: [e-mail]


------------------------------

From: [e-mail] (Wade Blomgren)
Subject: nVIR virus - you may think you don't have it...
Date: 19 Mar 88 01:49:13 GMT
Organization: UCSD Academic Computing Services

An interesting thing...for some reason (I don't think it is related to
the virus), when opening a System File with ResEdit while booted from
that same system, a large number of resources INCLUDING 'nVIR' don't
show up in the ResEdit resource list. Even stranger is the fact that
although a certain number of INIT's show up, the INIT 32 from the virus
does not show up.  It is only when booted from another disk  that I can
see the virus related resources (as well as a number of  other
resources) in that system file. Does anybody know why this is?

Anyway, check again from a separate boot disk - you may have the virus.
I thought I was fine, but upon closer examination I found I was quite
seriously affected.

Also, note that the nVIR virus does seem to infect the Finder, the DA
Handler, as well as normal (APPL type) applications. I don't know  what
the significance of this is as far as its ability to reproduce..
--
Wade Blomgren
[e-mail]  or ..ucsd!sdacs!wade


------------------------------

From: [e-mail] (Alexander M. Rosenberg)
Subject: Re: nVIR virus - you may think you don't have it...
Date: 19 Mar 88 06:10:25 GMT
Organization: University of California, Santa Cruz; CATS

Intreuging, Captain. Are you using MultiFinder? If you are, then the
reason the resources don't show up is MultiFinder, otherwise, then
something very interesting is going on...

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~  Alexander M. Rosenberg  ~ INTERNET: [e-mail]   ~ Yoyodyne    ~
~  Crown College, UCSC     ~ UUCP:...!ucbvax!ucscc!ucscb!alibaba~ Propulsion  ~
~  Santa Cruz, CA 95064    ~ BITNET:[e-mail]  ~ Systems     ~
~  [phone]       ~ Disclaimer: Nobody is my employer  ~ :-)         ~
~               ~ so nobody cares what I say.    ~          ~


------------------------------

From: [e-mail] (Chuq Von Rospach)
Subject: Re: PrintMonitor -- Out of Memory Problems
Date: 20 Mar 88 00:33:59 GMT
Organization: Fictional Reality

>besides the finder, leaving me some 600K free. While I was investigating this
>I noticed that Printmonitor was filling up its default 78K partition, and
>suspecting this was the problem I increased it to 120K.

Some system disks seem to have gotten out with a 78K partition for
printmonitor. The real standard size is 80k. I run mine at 82K because
I'm paranoid (my disks say 78K...)


Chuq Von Rospach            [e-mail]        Delphi: CHUQ

                               Speed it up. Keep it Simple. Ship it on
time.
                                                            -- Bill
Atkinson


------------------------------

From: [e-mail] (ephraim vishniac)
Subject: QuickerGraf 1.1
Date: 20 Mar 88 00:17:21 GMT
Organization: Thinking Machines Corporation, Cambridge, MA

I found QuickerGraf 1.1 on a local bulletin board today.  The benchmark
timings on it are only slightly different than on 1.0, so I imagine it's
a bug-fix version.  Does anyone know for certain?

Curiously, it appears to have a creation date of Mon, Feb 6, 2040; 6:28
AM.
--
Ephraim Vishniac                      [e-mail]
Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142-1214

     On two occasions I have been asked, "Pray, Mr. Babbage, if you put
     into the machine wrong figures, will the right answers come out?"


------------------------------

From: [e-mail]
Subject: Re: Prototyper vs. Doing it Yourself
Date: 16 Mar 88 19:14:00 GMT


I think you can learn a lot from a prototyping tool.  You can design an
elaborate user interface, and then look at the code it generates. One of
the best ways to learn is by seeing and imitating.  So watch how the
prototyper generates code for an application, and learn to imitate it.

Don Gillies {ihnp4!uiucdcs!gillies} U of Illinois
            {[e-mail]}


------------------------------

From: [e-mail] (Jonathan Pratt)
Subject: PrJobMerge, etc.
Date: 18 Mar 88 17:48:48 GMT
Organization: University of Colorado, Boulder

What is the correct way to merge print jobs when, for example, an
application has been given several files to print by the Finder?  I am
still using the old telephone book pre-release of IM (i-iii), and some
of the statements don't seem to hold.  That is, I can't get the results
of the first PrJobDialog call to apply to subsequent print jobs,
regardless of calls to PrJobMerge, PrDefault, etc.  The desired settings
seem to end up in PREC #1, but I doubt this should be accessed directly.
 Any suggestions?

Jonathan Pratt  {[e-mail]}  University of Colorado


------------------------------

From: [e-mail] (David Duffy)
Subject: Hard Disk Icon
Date: 18 Mar 88 20:47:12 GMT
Organization: Citicorp/TTI, Santa Monica


I want to find a way to display the icon associated with a SCSI disk in
a small program I am writing, but I haven't been able to figure out how
to find it. I recall from previous postings that the icon is somewhere
in the driver, and I assume that the icon is loaded into memory when the
disk is mounted.  Where is it, and how can I grab it?

                      Dave Duffy


------------------------------

From: [e-mail] (Michael Gleicher)
Subject: Filling an arbitrary quardrangle
Date: 19 Mar 88 16:56:27 GMT
Organization: Duke University CS Dept.; Durham, NC

Help!

I need a routine to fill and arbitrary quadrangle, defined by 4 points
in 2-space. I can't use a fill or flood type routine because there is
most likely junk underneath where this polygon is going and I do not
want outlines. Speed is the critical consideration.

A reference to an algorithm, or even better, some C code (I'm lazy)
would be VERY much appreciated.

Thanks,
    Mike
--
Michael Lee Gleicher            (-: If it looks like I'm wandering
    Duke University            (-:    around like I'm lost . . .
E-Mail: [e-mail])(or uucp    (-:
Or P.O.B. 5899 D.S., Durham, NC 27706    (-:   It's because I am!


------------------------------

From: [e-mail]
Subject: Asher Engineering ADB Trackball review.
Date: 20 Mar 88 05:25:24 GMT
Organization: The Portal System (TM)

I have just received my long awaited trackball from Asher Engineering.
Its a handsome looking unit that fits beautifully next to my MAC ][
extended keyboard.

Operating the ball feels nice, and I like the two buttons, one for
clicking, and one for shift-click.  Everything works smoothly, EXCEPT:

whenever I RESET my machine, the trackball goes (zzzz) DEAD !!!!  The
mouse, still connected to the otherside of the trackball works great,
but NOT the trackball.  IF, on the other hand, I shutdown my machine
(instead of resetting) everything is nice and dandy.. Both the trackball
and the mouse work fine.

Any suggestions ??
                   - ILAN Rabinowitz -  with ILANET
  [e-mail]


------------------------------

From: [e-mail] (Stew Rubenstein)
Subject: Re: Quickergraf bugs...
Date: 21 Mar 88 01:08:39 GMT
Organization: Aiken Computation Lab Harvard, Cambridge, MA

In article <[e-mail]> [e-mail] (Tom Lippincott,
..ucbvax!bosco!lippin) writes:
>Recently [e-mail] (Dave Platt) said:
>>Apple has apparently changed the MDEF so that it can recover gracefully
>>if it can't get a pixmap big enough to save the screen pixels;
>
>This causes a problem for me.  Since there are so many ways for
>out-of-memory problems to screw up the toolbox, I've responded by
>writing a growzone function which, when it can't scrounge memory, will
>unload most segments, put up an alert, and then longjmp back into the
>main event loop.  But this makes some menu choices fail even when
>MenuSelect could get by without the memory.
>
>What I want is a way to tell if a memory request is vital or not.  I
>can write this into my side of the code, but I know of no way to test
>this when it's a toolbox call that needs the memory.  Is there one?
>Will there be one eventually?  (This is all grungy stuff that would be
>better handled by the OS anyway, I say.)

Low memory handling on the Mac is a bitch.  There isn't any way to know
when a memory request is critical, except to know what the toolbox needs
the memory for.  You have to assume that any request is critical.  This
is not far from the truth - memory allocation failures are handled very
poorly by the toolbox.  In my apps, I have routines Critical() and
NonCritical(), which clear and set a flag checked by the growzone
function.  Then I have:

    INT32 MyMenuSelect(thePoint)
        Point thePoint;
    {
        INT32 result;

        NonCritical();
        saveGhost = GhostWindow; /* MenuSelect will not update properly */
        GhostWindow = 0;     /*   if you use GhostWindow.  */
        result = MenuSelect(thePoint);
        GhostWindow = saveGhost;
        Critical();
        return result;
    }

I also have a NewHandleNC() which I use for noncritical memory
allocations in my own code.  Another useful trick is to allocate a
couple of buffers at the start of your program so that you have
something to release when the growzone proc is called.

Finally, it's important to preflight every memory request that you can.
For example, before you call a routine in another segment, do a
GetResource on the right CODE segment and check to see it succeeds.  A
failure to load a CODE segment causes an immediate system error.  The
GetResource won't waste much time, but you have to identify all the
intersegment calls and have some way of telling what segment it's in. In
MPW it's easy because it names the resources.  For example:

    if (PreFlightCall(SEG_RotateFrob))
      {
        RotateFrob();
        UnloadSeg(RotateFrobox);
      }
    else
      {
        Alert (ALRT_notEnoughMemToRotateFrob, (FilterProc) 0);
      }

It's especially hard to preflight QuickDraw region operations.  I assume
that an upper bound on the size of a region is proportional to the area
of the bounding rectangle times an empirically derived fudge factor
related to the likely complexity of the region.  You can also use MapRgn
to do the operation on a scaled-down region first, as suggested in
Inside Macintosh, but I find this too time consuming for most purposes.
--
Stew Rubenstein
Cambridge Scientific Computing, Inc.
UUCPnet:    seismo!harvard!rubenstein            CompuServe: 76525,421
Internet:   [e-mail]       MCIMail:    CSC

------------------------------

End of Usenet Mac Digest
************************
-------